The invention relates to client-server systems and methods for transferring data via a network between a server and one or more clients that are spatially distributed (i.e., situated at different locations), and where at least one local client computer provides a user interface to interact with at least one remote server computer which implements data processing in response to the local client computer.
The Internet World Wide Web (WWW) architecture provides a very flexible, powerful, and potentially extensible programming model. As shown in FIG. 1, denominated xe2x80x9cPrior Artxe2x80x9d, applications and content are presented in standard data formats, and are browsed by applications known as web browsers. The web browser, 11, is a thin client, networked application, i.e., it sends requests, 21, for named data objects to a web or network server, 13, and the web or network server, 13, responds with the data encoded, 31, using the standard formats.
The WWW standards specify many of the mechanisms necessary to build a general-purpose application environment, including:
1. Standard naming modelxe2x80x94All servers and content on the WWW are named with an Internet-standard Uniform Resource Locator (URL).
2. Content typingxe2x80x94All content on the WWW is given a specific type thereby allowing web browsers to correctly process the content based on its type.
3. Standard content formatsxe2x80x94Heretofore; all web browsers have supported a set of standard content formats. These include the HyperText Markup Language (HTML), the JavaScript scripting language, and a large number of other formats.
4. Standard Protocolsxe2x80x94Standard networking protocols allow any web browser to communicate with any web server. The most commonly used protocol on the WWW is the HyperText Transport Protocol (HTTP).
This infrastructure allows users to easily reach a large number of third-party applications and content services. It also allows application developers to easily create applications and content services for a large community of clients. However, the success of the WWW and the underlying ATM and TCP/IP protocols has spurred new applications and rapid growth, limited only by the constraints of the underlying programming tools and page delivery languages. This has required optimizations, extensions, and xe2x80x9cwork arounds.xe2x80x9d This is especially so in the wireless or handheld environment.
The wireless or handheld environment presents challenges. The devices are physically small; they have low processor power, low memory capacity, small displays, narrow bandwidths, frequently with embedded communications software, and frequently with touch pads in addition to or instead of keypads. The Wireless Application Protocol (xe2x80x9cWAPxe2x80x9d) has been developed for these portable devices.
The Wireless Application Protocol (xe2x80x9cWAPxe2x80x9d) programming model is similar to the WWW programming model. Optimizations and extensions have been made in order to match the characteristics of the wireless environment. WAP content and applications are specified in a set of well-known content formats based on the familiar WWW content formats. Content is transported using a set of standard communication protocols based on the WWW communication protocols. A micro browser in the wireless terminal co-ordinates the user interface and is analogous to a standard web browser.
The WAP protocol defines a set of standard components that enable communication between mobile terminals and network servers, including:
1. Standard naming modelxe2x80x94WWW-standard URLs is used to identify WAP content on origin servers. WWW-standard URLs are used to identify local resources in a device, e.g. call control functions.
2. Content typingxe2x80x94All WAP content is given a specific type consistent with WWW typing. This allows WAP user agents to correctly process the content based on its type.
3. Standard content formatsxe2x80x94WAP content formats are based on WWW technology and include display markup, calendar information, electronic business card objects, images and scripting language.
4. Standard communication protocolsxe2x80x94WAP communication protocols enable the communication of browser requests from the mobile terminal to the network web server.
An example WAP-compliant network is shown in FIG. 2, denominated xe2x80x9cPrior Art.xe2x80x9d In the example, the WAP client, 12, communicates with a web server, 14, through a WAP gateway, 15.
The WAP gateway, 15, translates WAP requests, 22, to WWW requests, 23, thereby allowing the WAP client, 12, to submit requests, 22, to the web server, 14. The gateway, 15, also encodes the responses, 33, from the web server, 14, into the compact binary format, 32, understood by the client, 12.
If the web server, 14, provides WAP content (e.g., WML), the WAP gateway, 15, retrieves it directly from the web server, 14. However, if the web server, 14, provides WWW content (such as HTML), a filter is used to translate the WWW content, 33, into WAP content, 32. For example, the HTML filter would translate HTML into WML.
The Wireless Telephony Application (WTA) server is an example origin or gateway server that responds to requests from the WAP client directly. The WTA server is used to provide WAP access to features of the wireless network provider""s telecommunications infrastructure.
The WAP architecture provides a scaleable and extensible environment for application development for mobile communication devices. This is achieved through a layered design of the entire protocol stack where each of the layers of the architecture is accessible by the layers above, as well as by other services and applications. The WAP layered architecture enables other services and applications to utilize the features of the WAP stack through a set of well-defined interfaces. External applications may access the session, transaction, security and transport layers directly.
WAP browsers understand the wireless mark-up language or WML as specified by the Wireless Application Protocol. WML is used to create the user interface that is rendered on the browser. WML is an extension of the extensible mark-up language or XML (the successor to HTML) and was developed specifically for wireless devices.
The views generated by the web engine travel through a web server and a WAP gateway server to reach the wireless network and the browser enabled wireless device. The WAP gateway server translates the data from the Internet protocol (HTTP) to the WAP protocol and binary encrypts (through the Wireless Secure Transaction Layer specification) and compresses the data.
The screens are generated on demand when a user requests the information from their wireless device.
An end user accesses the server over the wireless network by entering a URL into the WAP browser. In addition, the wireless handset must be configured to dial into a modem bank and a remote access server (RAS) inside the enterprise""s firewall. From the RAS, the user connects over a LAN to the WAP Gateway Server and then to the web server. The protocol is again HTTP inside the firewall and security is not a perceived issue since the transfer from the WAP protocol to the Internet protocol occurs inside the firewall.
Alternatively, the end user may access the WAP server at a mobile carrier, and the mobile server/WAP server communicate in HTTP over an internet, an intranet, or a LAN, with a Web Server.
The WAP standard specifies two essential elements of wireless communication: an end-to-end application protocol and an application environment based on a browser. The application protocol is a layered communication protocol that is embedded in each WAP-enabled user agent.
The network side includes a server component implementing the other end of the protocol that is capable of communicating with any WAP device. Often the server component takes the role of a gateway routing the requests from the user agent to an application server. The gateway can be physically located in a telecom network or a computer network, building a bridge between the wireless network and the computer network.
The WAP application consists of a server application and a client application that the gateway downloads from the application server to the device (user agent) for execution. WAP provides a standard application environment consisting of a browser and a script interpreter. The browser is similar to a web browser and handles content described in WML (or HDMLxe2x80x94Handheld Device Markup Language) and a JavaScript-like scripting language called WMLScript. WML and WMLScript are designed for use in wireless, narrowband networks, and they are both binary encoded for optimum transmission efficiency.
In WAP, the content and the applications are addresses with a URL. The WAP operates as follows under the WAP Protocol:
1. The user enters a URL, as by pressing a phone key that has a URL request assigned to it.
2. A user agent in the device sends a URL request to a WAP gateway using the WAP protocol.
3. The WAP gateway creates a conventional HTTP request for the specified URL and sends it to the web server.
4. The web server processes the HTTP request. To process the request he web server runs a backend application or fetches some WML files and adds HTTP headers to them.
5. The web server returns the WML file or the WML output from the application server with the added HTTP header. A WML file is also called a WML deck. A WML deck consists of one or more xe2x80x9cscreensxe2x80x9d called cards.
6. The WAP gateway verifies the HTTP header and the WML content and encodes them to binary form. The gateway then creates a WAP response containing the WML and sends it to the user agent.
7. The user agent receives the WAP response. It processes the WML response and displays the first card of the WML deck to the user.
Steps 4 and 5, above, are specified functionally and generally, without providing on how the xe2x80x9cserverxe2x80x9d is to go from WML to HTTP, process in HTTP, recover WML xe2x80x9cdecksxe2x80x9d and content, and send the decks and content to the WAP gateway without loss of information.
Moreover, the Wireless Application Protocol and the Wireless Markup Language is merely exemplary of a class of new browsers, browser protocols, and page delivery and markup languages that are not fully compatible with HTML and XML but that co-exist with HTML/XML servers. The set of these browsers, browser protocols, and page delivery and markup languages will only grow over time, and a clear need exists for providing compatibility and interoperability between them and existing web servers and application servers.
The invention relates to client-server methods and systems where various clients that use different markup languages may use the same server, which can serve pages in various languages. The client may be a thin client or browser, as that term is generally understood. The server is configured to parse the request from the client to determine both the language of the request and the information requested. In the current implementation, through various configuration methods, the HTTP server associates a markup language with each virtual directory. Clients that want to request a particular markup language route their requests to the appropriate directory. The system directs requests in those virtual directories to components that serve the correct markup language. This may be done dynamically. The server, who may include a web server, additional web server software, a web engine, and associated metadata repositories and tools, recovers information including browser-compatible views, applets, and templates from the metadata repository associated with the server. The server uses the browser compatible views, applets, and templates to render a page to the client including data, information and views in the language of the request. The rendered views are displayed in a language supported by the client or browser.
In the method and system of the invention browser or client request for pages includes tokens, which may be of the form xe2x80x9cstart.swexe2x80x9d followed by one or more commands of the type xe2x80x9cSWEappletxe2x80x9d or xe2x80x9cSWEviewxe2x80x9d to specify the actions, and objects requested. The server obtains objects referred to by the tokens, by taking templates from the repository, inserting code, and sending the tokens the server and gateway to the browser or client. The tokens specifying the language of the request are embedded in the request from the client or browser, as in
HTTP://www.mysite.com/myapp/start.swe?SWEview=xe2x80x9d . . . xe2x80x9dandSWEapplet=xe2x80x9d . . . xe2x80x9dandSWEc md=xe2x80x9d . . . xe2x80x9dandSWEmethodName=xe2x80x9d . . . xe2x80x9d
where the tokens include start.swe, SWEview, SWEapplet, SWEcmd, and SWEmethodName. No technical importance should be attached to the specific names, which are arbitrary, and that look like xe2x80x9cSWExxxxe2x80x9d, or that they are specifically xe2x80x9cViewxe2x80x9d, xe2x80x9cMethod Namexe2x80x9d, etc., or that xe2x80x9cstart.swexe2x80x9d matters. The expression illustrates that the URL is a script of business or application terms, including business objects, UI objects, name commands to be processed by them, and an implicit command to reply with an HTTP response that renders their resulting states. These items are modeled in a metadata repository that is not dependent on markup language. The Web Engine renders these markup language-independent metadata objects in the markup language of choice. That""s the essence of the invention. Some requests include additional information in the request body, which is not visible in the URL.
In a preferred embodiment of our invention the client is a wireless client configured to send requests incorporating tokened requests for pages to the server and receive pages from the server, where tokened requests specify the language of the request and of the requested response, as WML, and where the server is configured to parse the tokened request from the client to determine the language of the request and the information requested; that is, WML, and recover information including views from a repository associated with the server; and to thereafter render a page to the client including information and views in the language of the request, as WML, and the view is a display with applets in the language requested by the client, as WML decks.
While the method and system of the invention have been described, illustrated, and summarized with respect to a class of wireless devices utilizing the Wireless Application Protocol (WAP) and the Wireless Markup Language (WML), it is, of course intended that the method and system of the invention may be employed in other browser or client configurations, formats, and form factors utilizing the WAP with WML, as well as in other clients and browsers with bandwidths, processor speeds and capacities, memory capacity, and/or input/out capacity markedly different from those characteristics of PC based browsers and clients. A particular aspect of the method and system of the invention is that it is intended to work with browsers or clients that use other markup languages., and is not to be limited to WAP or WML
According to our invention a client-server method and system is provided where the server is configured to receive requests from the client. send responses to the client. The server is further configured to interpret the request to determine at least one of the language, protocol, or syntax in which the client sends requests and receives responses, and to also interpret the request to determine data submitted by the client, that should be used to create, modify, delete, or append to business objects or user data in the server system. The system then recovers metadata or descriptive information from a metadata repository associated with the server; and creates a response in the preferred language, protocol, or syntax of the client. This response represents the states of some objects in the server system following the processing of the request, properly represented in the language, protocol or syntax preferred by the client.
The system and method further includes the capability for interpreting the request to determine the classes and instances of business objects and user data to associate with the request, and interpreting the request to determine commands to be executed by the business objects. This is followed by interpreting the request to determine data submitted by the client to do one or more of creating, modifying, deleting, or appending to business objects or data in the server.
This interpreted data is used to recover user data or business data from database servers or application servers associated with the server. In a preferred embodiment the server is further configured to optimize the handling of subsequent requests from the same client, by embedding information in early responses to the client, where that embedded response information will be included in subsequent requests from the same client, and where that embedded request information will be used by the server during the processing of subsequent requests.
The server response is in the form of an object intended for display in a client with a user interface. The object may be a page. Alternatively, the server response may be in the form of machine-readable data.
Typically, the client request includes tokens specifying the language requested, and at least one tokens in the request identifies metadata objects that are available to the server system. These metadata objects are selected from the group consisting of views, pages, applets, controls, and objects having user interface semantics. Alternatively, the objects may be business objects, business components, and objects having non-interface semantics, or they may be metadata objects having non-interface semantics, such as linkages to other objects, containment, and association. Associations, are well known from object oriented programming, and in the context of the method and system described herein, an association has a user interface representation. Alternatively, hypertext may be provided to allow or facilitate access to detailed information through drilldown in the user interface.
The client request further includes tokens that specify instances of object types specified in the metadata repository to be created, modified, or deleted. Part of the metadata associated with an object is in the form of one or more template objects, which template objects contain rules for representing the object in various languages, protocols, or syntaxes. The template object is typically stored as a file in the server file system, or as a binary object in a database or other on-line storage system. Each template object is associated with a particular language, protocol, or syntax. The server system is configured to identify a client""s preferred language, protocol, or syntax, and to use a template object associated with that preferred language, protocol, or syntax, to represent an instance of the parent metadata object to the client, and, if necessary, to iterate and enumerate child or subordinate objects.
Some of the rules for representing the object in various languages, protocols, or syntaxes pertain to containment. Other rules are placeholders for specific properties of the metadata object. Moreover, some of the rules include specifiers of a language, protocol for representation of an instance of the metadata object. Still other rules are constants or literals, to enable the representation of portions of the metadata object without processing by the server system beyond inserting the constants or literals into the body of a response to client requests. The rules have multiple variants, each specifying a different language, protocol, or syntax.
A default value to language, protocol, or syntax. Thus, the server may represent the instance of the metadata object by: (1) searching for a rule that specifies the preferred language, protocol, or syntax of the client, and (2) use that rule, or (3) in the absence of a rule, search for a rule that does not specify a language, protocol, or syntax, and use that rule as if it specified the client""s current preference.
In an embodiment of the method and system the server recognizes that the client""s preferred language is a markup language. The markup language is selected from the group consisting of SGML, HTML, WML, HDML, and XML. Moreover, as noted above, the server is configured to create responses in multiple markup languages. The server may use similarities among various markup languages, to optimize the creation of responses in the different markup languages, and also in the case where one markup language is derived from another markup language, the server can use common components or procedures that represent metadata objects in the parent language. This is true whether or not there is an actual parent language. For example, the system and method described herein treats two or more markup languages as being derived from an artificially constructed markup language. The server may optimize representations in these languages using a hypothetical or actual parent language, where the parent language is the artificial or previously unknown language. A preferred example of this type of optimization is the rendering of objects in WML and HTML, which may be considered to share an artificial or previously unknown language as their parents.
In finding a parent language, the derivation structure of the languages includes more than one layer of derivation. This is also true in the case where an artificial language occupies a position in the derivation structure between one or more known languages. For example, WML and HTML, though both are derived from, or are variants of, SGML, in order to achieve the optimizations, both may be considered variants of another, artificial language, which is considered to be derived from SGML.
Another aspect of the method and system described herein is that the properties of a metadata object that are identified by placeholders in the templates will frequently have different representations in different languages, protocols, or syntaxes, and the server is configured to represent this object in the language of the client. This requires that the server be configured to identify the client""s language, protocol, or syntax, and associate it with the current client request. The server does this by querying the current context for the preferred language, protocol, or syntax, and uses this preference to create a response including representations of objects in the preferred language, protocol, or syntax. More particularly, the server is configured to query the context for the preferred language of representation when representing every object in the system.
Another aspect of the method and system described herein is that object-oriented programming techniques, such as those that are available using C++ or Java, may be effectively used to implement the notion that objects represent themselves, where a metadata class has an associated C++ or Java or other programming class, and where the server represents an instance of a metadata object class by creating an instance of the associated programming class, and calling a function or method for that instance that will represent the instance in the correct language, protocol, or syntax. Thus, where the class structure of objectsxe2x80x94both metadata objects and programming objectsxe2x80x94is elaborate, in particular, where a class of metadata object, for example xe2x80x9cAppletxe2x80x9d, may have a set of specialized programming classes associated with its instances, it is desirable the various specialized programming classes should be related, either through inheritance or through interface implementations, to a single class or interface that is considered the base programming class or base programming interface for the metadata class. Where the server represents an object of one of these derived classes, this is accomplished by obtaining the name of the derived programming class from the instantiated metadata object, instantiating an instance of that class, and then calling a function or method of that programming instance that will represent it in the preferred language, protocol, or syntax. Additional object-oriented programming techniques may used to implement the notion that objects that contain other objects, either logically or in some user-interface sense, may represent themselves and their contained objects, including by calling functions or methods on child or contained objects, where those functions or methods correctly represent the child or contained objects. The containment structure may have more than 2 layers. The request context may queried for the preferred language, protocol, or syntax, as when some parent objects are prepared for representation, and those parent objects are responsible for causing their contained objects to be represented in the correct language.
The context may be queried only when some objects are represented, and where those objects are responsible for causing their contained or child objects to be rendered in the correct language, protocol, or syntax., or where parent or containing objects directly represent their own child or contained objects in the correct syntax. When the parent or containing objects call functions or methods on their child objects, these calls contain arguments or other context or have function or method names, and where these various means identify the preferred language, protocol, or syntax for the representation, and the child or contained objects use this context to render in the preferred language, protocol, or syntax.
The preferred representation context may be included in an argument to the function or method, or implied by the specific function or method that is called. If the function or method names are well-known to programmers of the system, for example if the server or parent object desires another object to be rendered in WML, it may call a function for that object called ShowWML, where it is well-known that this function represents the object correctly in WML.
Where the well-known function is virtual, either explicitly as in C++ and similar languages, or implicitly as in Java and similar languages, and where the desired effect is for specialized representation methodsxe2x80x94specialized either for metadata classes or for metadata instances as described in claim specialized classes may be used to handle the representation correctly.
To optimize the processing of languages that are related, the task of representing an object is first dispatched to the logic that handles the most derived appropriate language, in an instance of the most-derived appropriate programming class. If an implementation is not available, the task is dispatched to the logic that handles the most-derived appropriate language, in the next-most derived programming class. This process continues until either an implementation is found and executed, or the least-derived programming class is found not to have an implementation for the most-derived representation language. In this case, the task of representing the object is dispatched to the handler for the next-most derived language, in the most-derived programming class. This method will cause the object to be represented in the most-derived available language for that object, by the most-derived programming object that has a representation available in that language.
Where the dispatching method is the use of well-known virtual functions, with one virtual function per representation language, with the base implementation of each representation language simply calling the virtual function for the next-most-derived language, and with implementations in derived classes and derived languages necessary only where the derived representation differs from the parent implementation. However, where programmers and configurators who can not extend or specialize the system using C++, Java, or other similar system programming languages, they may write scripts or other event-driven programs in JavaScript, ECMAScript, Visual Basic, or other scripting languages, to specialize the representation of objects in the system, and where they should expect that these scripts will represent the objects in the preferred language. Where these scripts are associated with particular metadata objects in the metadata repository, and where during the servers creation of the representation of an instance of any of these objects, the script is called, and its arguments, context, and methods may be used in the script to get information about the instance, including the preferred representation language, protocol, or syntax for the object. Where these scripts are stored in the metadata repository, whether that be in database form or some compiled or other binary form. Where these scripts are stored in the template objects, which may be files in some part of the server infrastructure""s file system.
The system is configured to identify the preferred language, protocol, or syntax of the client, receiving data from the client, and using the data to add, modify, or delete records in the server database. For example, the preferred language may be associated with encoding of the data, and where the server removes this language-dependent encoding, and stores the data in a language independent format. Thus, the format may be persistently associated with the data.
Tags specifying the language of the request are embedded in the request.
The client may be an HTML browser, and the preferred language for representing objects for this client is HTML. Alternatively, the client may be an HTTP browser or wireless device for which the preferred language for responses from the server system is WML.
In still other situations, the preferred language for the client, to be used to create responses from the server system, is XML. In still other applications, the preferred language for the client, to be used to create responses from the server system, is a language which does not include user interface elements.
In one exemplification, the client is also a gateway server for lower level clients. For example, the client may be an HTTP client and also a gateway server to wireless browser clients. In this exemplification, wireless clients request pages from the client via the WAP protocol, and the gateway server transforms the WAP/WML requests from the wireless or other browsers into HTTP/WML requests which it submits as a client to the server. The gateway server receives HTTP/WML responses created by the server, and transforms them into WAP/WML responses which it returns as a gateway server to the wireless browser clients which initiated the request process.
In this embodiment, the client is an HTTP client and also a server to wireless browser clients, and the wireless clients request pages from the client via the WAP protocol. The wireless clients prefer WML as the language for representation of object states in the server system, and the gateway server acts as a client to the higher level server. The gateway server transforms the WAP/WML requests from the wireless or other browsers into HTTP/WML requests which it submits as a client to the higher level server, and takes the HTTP/WML responses created by this server, and transforms them into WAP/WML responses which it returns as a server to the wireless browsers which initiated the request process.
The server is configured to accept requests from multiple clients, in multiple markup languages and to respond to a client in the markup language used by the client.
In one embodiment the client is a wireless client configured to send requests incorporating tagged requests for pages to the server and receive pages from the server. The tagged requests specify the language of the request and of the requested response, and the server parses the tagged request from the client to determine the language of the request and the information requested; recovers information including views from a repository associated with the server; and renders a page to the client including information and views in the language of the request, wherein said view comprises a display and applets in the language requested by the client.
Typically, the view received by the client will contain data from the server.
The client request specifies a directory on the server system, where the directory is associated with the preferred language, protocol, or syntax for the client.
The server is configured to read data embedded in header responses, for example, where the server is configured to embed information included in one or more of URIs, URLs, or URNs in the server responses, and where the client is configured to use the one or more of URIs, URLs, or URNs to submit further requests to the server.
In one embodiment, the server interprets an early request from a client as a persistent preference for language, protocol, or syntax, and stores this preference, using the stored preference to retrieve the language, protocol, or syntax preference of the client from the dictionary or other cache.
For example, the server may create a state description or session for the client during an early request from the client, and thereafter associate a particular language, protocol, or syntax with the session, and maintain the session in expectation of receiving later requests from the client. The embedded information identifies the session, thereby identifying the client""s preferred language, protocol, or syntax.
As described above the server may be a multi-tiered server system, comprising multiple programs and where the various are distributed among the different tiers of the system.